在這系列的文章中，我們鮮少聊到設計與重構，但是我們增加測試的目的，是為了就產品的品質，而產品的品質要好，高品質的程式碼是必不可少的。測試可以支持我們進行重構，調整設計，把程式碼調整成更好維護調整的狀態，以支持產品未來新增需求，讓產品有足夠的動能持續盈利。

支持持續修改

只要我們的產品持續盈利，我們就會每天在現有產品加新功能。持續的新增與修改功能，也意味了我們得每天面對我們舊的程式碼，思考如何調整以應付新的需求。無論是軟體缺乏測試，抑或是設計不良，都會一步一步的減緩我們的開發速度，直到完全改不動的那一天，就只剩下翻掉重寫的可能性了。翻掉重寫需要花費許多的物力與人力，卻沒能對使用者帶來真正的價值。

為了避免落入這樣的情況，我們就得常常重構我們的程式碼，就像種植花草樹木一樣，需要澆水，需要修剪，重構程式碼能讓程式更容易維護。想要常常要重構，我們就要有測試的保護，畢竟我們不可能每一次修改就手動測試過所有功能。

有了測試之後

當我們有測試保護之後，就可以開始重構程式碼，我們得先察覺程式碼中的 Code Smell，根據不同的 Code Smell 採取不一樣的措施，讓程式碼符合各種的設計原則，例如：SOLID 原則、DRY 原則 …等。除了設計原則之外，我們也得注意程式碼的可讀性是否足夠，在 Kent Beck 的實作模式中就有談到，簡單程式設計的四個原則，其中第二條就 Reveals Intent (Self-Documenting Code) 程式能夠表達出意圖，我們必須花時間重構，直到程式簡單到顯然沒有缺陷，而不是複雜到沒有明顯的缺陷。

除了知道要重構成什麼樣子之外，如何重構也很重要，再重構 : 改善既有代碼的設計中，詳細介紹了各種不同重構手法，也有討論哪些 Code Smell 適合哪些重構手法，也是開發人員必須學會的技能之一。重構技巧同樣可以用在開發 Flutter 上，例如在其他程式語言中，會透過抽取方法來隱藏實作細節，拆分方法的職責，在 Flutter 中使用抽取 Widget 也是相同的效果。

盡量避免在沒有測試的狀況下重構

重構的定義的是「在不改變軟體外部行為的前提下，改變其內部結構，使其更容易理解且易於修改」，那我們怎麼知道行為沒有被改變呢？首先，我們得確保程式是在有測試保護情況下開始，畢竟如果沒有測試，開發人員就必須頻繁的手動測試，才能確保重構後的程式行為沒有被破壞。但是當我們碰到遺留代碼的時候該怎麼辦呢？先重構與先寫測試就變成雞生蛋，蛋生雞的問題。

其實，遺留代碼還是能透過一些其他測試方法來測試，例如：特徵測試，什麼是特徵測試呢？簡單來說，就是我們在修改程式碼之前，先用執行一次程式並紀錄結果，當修改完程式碼之後，在測試一次，期望重構前與重構後的結果一致。在 Flutter 中本身有提供方法讓開發人員用特徵測試，也有許多套件可以支持我們做特徵測試，例如：alchemist，透過比較修改前與修改後的畫面差異，來確認重構是否破壞了原有行為。

沒有測試也想改

不過想當然爾，如果真的碰到要處理遺留代碼狀況時，這些程式碼九成也不會有特徵測試可以使用，當情況一緊急，我們也只能在沒有測試的情況下硬著頭皮改，但是這並不意味著我們可以大翻修，而是必須依照安全的修改步驟來小範圍的修改，然後再小範圍的加上測試，一點一點的讓整個專案的程式碼都有測試保護，在之前介紹過的 Working Effectively with Legacy Code 有更詳細的說明。小範圍的調整，除了能控制程式改壞的風險之外，也能讓這次修改的時間控制在合理範圍之中，畢竟我們修改程式碼是為了對客戶產生價值，不應該浪費時間在修改不需要修改的功能上面。

小結

如果寫測試只是單純的為了檢查產品有沒有問題，未免過於可惜，測試除了確保產品品質之外，也能幫我們優化程式碼的品質。畢竟程式改壞了測試會提醒，我們就能放心重構，即便功能越來越多，越來越複雜，也不至於拖垮開發進度，讓產品得以穩定成長持續盈利。